问 1:impacket-psexec 所支持的四种认证方式对比说明
impacket-psexec 是 Impacket 工具集中最常用的横向移动工具之一。它支持 四种主要的身份验证方式,每种方式各有特点、适用场景、安全性和兼容性。
✅ impacket-psexec 支持的四种身份验证方式对比:
| 编号 | 身份验证方式 | 命令参数方式 | 使用协议 | 需要 DC | 凭证形式 | 适用场景 |
|---|---|---|---|---|---|---|
| ① | 明文密码登录 | <domain>/<user>:<password>@<target> | NTLMv2 | ❌ 否 | 明文密码 | 快速测试、常见环境、兼容性最好 |
| ② | Hash 登录 (PtH) | -hashes :<NTHASH> | NTLMv2 | ❌ 否 | NTLM 哈希 | 渗透测试常用、抓到哈希即可横移 |
| ③ | Kerberos AES Key | -k -aesKey <AES256/128 hex> | Kerberos | ✅ 是 | AES key(十六进制) | 高权限攻击者、持票攻击 |
| ④ | Kerberos 票据登录 | -k(自动加载 ccache) | Kerberos | ✅ 是 | TGT/TGS 票据文件 | 已登录域用户,或已有票据 |
🧠 详细说明与示例:
✅ ① 明文密码登录(默认)
impacket-psexec corp.local/administrator:Passw0rd!@192.168.1.10
- 💡 使用 NTLMv2 协议进行身份验证;
- Impacket 不把密码发过去,而是构造 challenge-response;
- 易用,但安全性低;
- 容易被 EDR 检测。
✅ ② Hash 登录(Pass-the-Hash)
impacket-psexec -hashes :aad3b435b51404eeaad3b435b51404ee CORP/administrator@target
- 💡 只需 NTLM hash,不需要明文密码;
- 常见于利用
secretsdump、mimikatz后的横移; - 和明文登录一样也是 NTLM 协议;
- 容易被检测,但效率高,攻击常用。
✅ ③ Kerberos AES Key 登录(Pass-the-Key)
impacket-psexec -k -aesKey <hexkey> corp.local/administrator@hostname.corp.local --dc-ip 192.168.1.1
- 💡 需要与域控制器通信以获取 TGT;
- 安全,难以检测;
- 前提是你知道用户的 AES 密钥,可以从
mimikatz中提取; - 支持 AES128 和 AES256;
- 目标主机名必须是 FQDN,不能用 IP。
✅ ④ Kerberos TGT/TGS 票据(ccache)登录
export KRB5CCNAME=/tmp/krb5cc_0
impacket-psexec -k corp.local/administrator@target --dc-ip 192.168.1.1
- 💡 不用密码、不用哈希、不用密钥,只用已获取的票据(
.ccache); - 非常适合持票攻击(Pass-the-Ticket);
- 必须是目标域用户且已有 Kerberos 登录票据;
- 最难被检测,最“隐身”。
🔐 安全性 & 检测对比:
| 验证方式 | 安全性 | 被检测概率 | 是否需要 KDC | 常见来源 |
|---|---|---|---|---|
| 明文密码 | ❌ 低 | ⚠️ 高 | 否 | 已知口令、弱口令 |
| NTLM hash | ⚠️ 中 | ⚠️ 高 | 否 | secretsdump、LSASS |
| AES key | ✅ 高 | ✅ 低 | 是 | mimikatz、Kerberoast |
| Kerberos 票据 | ✅ 高 | ✅ 最低 | 是 | klist, kerberos::list |
🧪 实战选择建议:
| 情况 | 推荐验证方式 |
|---|---|
| 拿到了明文密码 | 明文登录或改为 hash |
| 拿到 NTLM hash(如 secretsdump) | 使用 -hashes |
| 拿到 AES 密钥(如 mimikatz) | 使用 -k -aesKey |
| 拿到 .ccache(如 linWinPwn) | 使用 -k + 环境变量 |
如果你不确定该选哪种方式,可贴出你现有凭证(脱敏后),我可以帮你确定最合适的命令。
问 2:它们对 target 的表示方式各有什么不同
很好的问题!在 impacket-psexec 中,不同的身份验证方式,对 target(目标主机)的表示方式确实 有显著不同要求,尤其是在 Kerberos 模式下。下面是详细对比说明:
✅ 总览:target 表示方式差异
| 认证方式 | 使用协议 | target 可以是 IP? | target 推荐格式 | 原因说明 |
|---|---|---|---|---|
| 明文密码登录 | NTLMv2 | ✅ 可以 | IP、主机名、FQDN | 纯 NTLM 协议,不依赖主机名 |
| Hash 登录 (PtH) | NTLMv2 | ✅ 可以 | IP、主机名、FQDN | 和明文一样,本地发起挑战响应 |
| AES 密钥 (Kerberos) | Kerberos | ❌ 不可以 | ✅ 必须是 FQDN(含域名)或 NetBIOS 主机名 | 需要构建 SPN,例如 host/win10.skylark.com |
| Kerberos 票据 (ccache) | Kerberos | ❌ 不可以 | ✅ 必须是 FQDN 或域内主机名 | Kerberos 基于主机名与服务票据匹配 |
🔍 详细解释(为什么 Kerberos 不允许 IP)
💡 Kerberos 的 SPN(Service Principal Name)机制:
-
Kerberos 验证目标服务时需要构造一个 服务主体名(SPN),如:
host/win10.skylark.com@SKYLARK.COM -
这个 SPN 要与 DC 上注册的服务完全匹配;
-
使用 IP 时构造出的 SPN 是非法的(如
host/192.168.1.10@SKYLARK.COM),DC 无法解析,导致错误:Kerberos SessionError: KDC_ERR_S_PRINCIPAL_UNKNOWN
✅ 示例:各种验证方式下如何写 target
| 登录方式 | 正确写法示例 | 错误写法示例 |
|---|---|---|
| 明文密码 | corp.local/user:pass@192.168.1.10 | ❌ 无 |
| Hash (PtH) | -hashes :<NTHASH> corp.local/user@10.0.0.5 | ❌ 无 |
| AES 密钥 (Kerberos) | -k -aesKey <key> corp.local/user@host.corp.local | ❌ IP地址 |
| Kerberos 票据 | -k corp.local/user@win10.corp.local | ❌ corp.local/user@10.0.0.5 |
🛠 小技巧:如何获取正确主机名(FQDN)
-
从 Mimikatz 中看主机名(
hostname,kerberos::list); -
使用 DNS 解析(如果设置好):
nslookup 192.168.56.50 -
使用 SMB 枚举工具获取 NetBIOS 名:
nmblookup -A 192.168.56.50
或者,直接让 /etc/hosts 帮你解决主机名解析问题:
echo "192.168.56.50 win10.corp.local" >> /etc/hosts
🧠 总结:
| 身份验证方式 | 是否可以用 IP 做 target | 推荐格式 |
|---|---|---|
| NTLM 密码 | ✅ 可以 | IP 或主机名 |
| NTLM Hash | ✅ 可以 | IP 或主机名 |
| AES 密钥 | ❌ 不可以 | 必须是主机名或 FQDN |
| Kerberos 票据 | ❌ 不可以 | 必须是主机名或 FQDN |
如果你不确定某个 IP 的主机名,我可以帮你分析环境并猜测出可能的 FQDN。你只需提供域名、主机 IP、Mimikatz 或 secretsdump 输出等信息。